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ABSTRACT 



An improved session control method and apparatus includes 
a client which establishes a session with a first server such 
that the first server can identify the client. When the client 
wishes to migrate from the first server to a second server, the 
client requests a session token from the first server. The 
session token is a data element generated by the first server 
which is unique over the client-server network being navi- 
gated and identifies the particular session with the first 
server. The session token is preferably a difficult to forge 
data element, such as a data element digitally signed using 
the private key of the first server. The session token is passed 
from the client to the second server to initiate migration to 
the second server. If session data is too bulky to be passed 
as part of the session token, the second server may use data 
from the session token to formulate a request to the first 
server for additional data needed to handle the state of the 
session. To minimize the transmission of data, the second 
server might maintain a version of the bulk session data and 
only request an update to the version of the data indicated in 
the session token. 

13 Claims, 3 Drawing Sheets 
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COMMON SESSION TOKEN SYSTEM AND the first server, the second server will interrupt the naviga- 

PROTOCOL ti° n process to require authorization information from the 

client. The usefulness of hypertext documents is greatly 

BACKGROUND OF THE INVENTION diminished if a user must enter a new login name and 

The present invention relates to the field of client-server 5 password each time a link is taken, 

protocols. More specifically, one embodiment of the inven- Session control for a single document is known. A URL 

tion provides for seamless migration of a session from one for a document available in a sessionless environment might 

independent cooperating server node to another. be a character string of the form: 

The global Internet has emerged as a model of a distrib- http://server.host .domain/directory/subdir/file 
uted network of networks. One application for which the 10 with "http://" indicating the protocol, "server. host.domain" 
Internet is increasingly used is to interconnect hypertext uniquely identifying the server, and "directory/subdir/file" 
transfer protocol (HTTP) servers to clients. The hypertext identifying the document to be served. Where the document 
transfer protocol is used to serve documents containing is not to be accessible to other than an authorized client, the 
hypertext references to client "browsers" on client systems URL might be of a form similar to the sessionless URL: 
connected to the Internet. The documents served by an 15 http://server.host.domain/dir...file?userfred+password 
HTTP server will often have hypertext references embedded In the session-specific URL, the user's name and pass- 
in the document which refer to documents on the HTTP word are included in the URL. While this is useful for 
server or documents on a completely different server. With making a reference to a single document for a specific user, 
such an arrangement, millions of documents have been it is not useful for passing sensitive session information 
linked to form the World Wide Web, which is an allusion to 20 because, the user name and password being in plaintext, it is 
the fact that these hypertext links might look like a spider too easily tampered with. 

web if a diagram of the documents and the links were drawn. Thus, what is needed is a method and apparatus for 

Hypertext, as such, was used in other contexts, such as maintaining a seamless and secure migration of a session 

help documentation, but those uses generally connected to a between a client and a first server to a session between the 

central document repository or even a single file with client and a second server, where the first and second servers 

references to locations internal to the file. What made the are independently controlled. 

World Wide Web more interesting and complex is the fact cmj(MAnv ^ ixr\/cKrrr/^Ki 

, . . . „ 4 j a t a a * • U4 SUMMARY OF THE INVENTION 
that a link in a first document stored on a first server might 

refer to a document on a second server where the author of 3Q An improved session control method and apparatus is 

the first document and the system operator of the first server provided by virtue of the present invention. In one embodi- 

had no editorial or system control over the second document ment of the present invention, a client establishes a session 

or the second server. with a first server such that the first server can identify the 

This independence of servers did not inhibit the naviga- client. When the client wishes to migrate from the first server 

tion of a client from server to server, since the reference for 35 to a second server, the client requests a session token from 

the link to be followed was fully contained in the document the first server. The session token is a data element generated 

where the reference was made. These self-contained refer- b Y ^e first server which is unique-over the client-server 

ences to information are referred to as "uniform resource network being navigated and identifies the particular session ^ 

locators" (URbs) because the reference was all that was with the first server. The session token is preferably a 

needed to locate the "linked-to" document. Since the URL is 40 difficult to forge data element, such as a data element 

a static data element, it is the same for every client, so the digitally signed using the private key of the first server and 

linked-to server could not identify who the client was. possibly encrypted. The session token might also be 

Several solutions to this shortcoming have been in common encrypted, using public key encryption or other methods, to 

use prevent the session token from being easily readable. 

The most common solution is to eliminate the need to 45 The session token is passed from the client to the second 

know who the client is. If the identity of the client is not server to initiate migration to the second server. In some 

needed, an HTTP server will serve documents to any client embodiments, session data is too bulky to be passed as part 

which requests a page. Of course, this solution is only of the session token. In such cases, the second server uses 

practical where the author of the linked-to document does tne session token to formulate a request to the first server for ■ 

not want to place any restrictions on who may view the page. 50 the data needed to handle the state of the session and the first 

If the author of the linked-to page wants to place restrictions, server provides the data to the second server. To minimize 

the client will have to enter into a "session" with the server transmission of data, the second server might maintain a 

/ where the client is first authenticated prior to the server version of the bulk session data and only request an update 

allowing access to the server. 7 10 tne version of the data indicated in the session token. 

One consequence of such an architecture is that, without 55 ln tne preferred embodiment, the token is passed in a URL \5cjT\ i ^ UiLL- 

some session control, the clients and servers must operate in (Uniform Resource Locator). However, it also might be 

a "stateless" manner, i.e., not tracking client identity, or any passed as an HTTP "cookie". (JCXVOU 

other variables, from request to request. Session control, A further understanding of the nature and advantages of 

when used, is usually done by a server requesting a login the inventions herein may be realized by reference to the 

name and a password from the client prior to serving 60 remaining portions of the specification and the attached 
documents. Where all the documents are stored on a single, drawings. 

server or a centrally controlled cluster of servers, session. ODTCC nccmiDnnM -rue no awimpc 

control only need occur when the client first visits the server. < DESCRIPTION OF THE DRAWINGS 

If a link from one document references a document on the FIG. 1 is a block diagram of a client-server network with 

same server, the session can be seamlessly continued from 65 which the present invention is used. 

the perspective of the client. However, if the link is to a FIG. 2 is a flowchart of a session migration process 

document on a second server not commonly controlled with according to the present invention. 



* 
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FIG. 3 is a schematic of a session token. identified as SI, S2, S3, etc. which are performed in ascend - 

FIG. 4 is a schematic of a request for out-of-band data. m g numerical order unless otherwise indicated. Before the ^ 

migration process begins, the client is in a session withctf^ 

DESCRIPTION OF THE PREFERRED server A (step SI). The client sends requests to server A and 

EMBODIMENTS 5 server A services those requests. How server A services 

FIG. 1 illustrates an overall structure of a client-server mose requests depends on what the request is and the current 

network 10 with which the present invention is used. Net- s,ate of the session - For exam P le > f ° r some re 9 uests ' server 

work 10 is shown comprising a client 12, two servers 14A, A mil only respond to the request if the state of the sess.on 

14B, the Internet 16, server connections 18A, 18B to Inter- wwh ,he = 1,ent "> dicales th . at ' he , chen ! » lo ^t in a ?. a " 

net 16 and a client connection 18C to Internet 16. As should >° authorrzed user. The state might also include ^variables which 

be apparent, more than two servers might be coupled by a "wdify the interaction i with the client such as the client s 

network to one or more clients, and the network need not be uscr » demographics If the demographics indicate the geo- ^ 

the global Internet, but can be any other network of coop- 8«phic location of the user or the users age, gender, etc the 

erating independent servers. One alternative platform for the server might modify advertisements presented to the client ^ 

present invention is an intranet rather than Internet, where 15 accordingly If the demographics indicate that the user is a ^ 

the intranet is an internal network within an organization sophisticated user, 'he server might send less help text 

using Internet protocols to communicate internal data. exchange for quicker transmission times When such state 

Depending on the size of the organization, the intranet might varial ? les are used, it should be apparent from this descrip- 

ccmprise several cooperating, but independent servers. <'° n that tbe "« 10 wh '« h lhe cUent 15 migrating needs to 

, .. ... . , , ... .. , . 20 have the same state variables so as to present a consistent 

In operation, server 14A interacts with client 12 yia ^ the ^ ^ m ^ ^ 

Internet 16 by sending and receiving data packete directed ^ ^ ^ Qns ^ ^ has a don ^ ^ fof 

at, and received from client 12. Client 12 also sends packets trackf and cachi Activit Peking fa uscful for 

to and receives packets from server 14A via Internet 16. ... . ,\ _ f , _ + u„f\u~ „ n „;„„^„ ~r <u~ ,.i; an , 

_ A \ t ^ . ... Web browser clients, so that the navigation or the client can 

Thus, at a network level higher than the transport level, there , . , , n . fil r t ** r * a 

' . . , . i t . t ' 25 be tracked. Caching is useful tor many types or clients and 

exists a logical channel 20A connecting client 12 to server . . . , , . b . , ... . . *. , 

„ JirT ^ & . 1 , ... 6 ... might be used to avoid sending data the server knows the 

14A. The equivalent can be said about server 14B, which djeat aire ad has 

connects to client 12 via a logical channel 20B. r * , ' , , ... 

, . Mn ... In step S2. the client makes a selection which server A 

Server 14A and 14B are ^cooperative servers in that they determines will be mi led< In lhe case of embedded 

both understand that client 12 might migrate from one server 3Q m{ {ion (nol shown)> server A would have anticipated the 

to another and facilitate that process. Un ike a centralized * ib , e ^ {{oa and inchlded ^ migration in f orrna tion 

access control system, however, servers 14A and 14B are in an HTML anchor on the page. Server A optionally verifies x 

separately controlled. if lhe c[ient is permitted t0 m i gra t e and then server A returns*f^ jj^V 

An example of session migration will now be described ( step S3 ) a session token 104 t0 ^ client ^ part of a URL ^ 

with reference to a migration of client from a server A to a 35 By i nc ] u ding the session token as part of the URL, a standard \£>& 

server B, which might be client 12, server 14A (source browser (i.e., one which is not aware of migration 

server node) and server 14B (target server node). The capabilities) can be used. The structure of a session token is 

session migration process begins when client 12 takes an shown in Table 1 and illustrated in FIG. 3. 

action which is to result in a session migration. The session 

migration moves the client's interaction from channel 20A 40 TABLE 1. SESSION TOKEN ELEMENTS 

to channel 20B in a way that is transparent to the client's i s erV er Node Identifier 

user, but that also maintains any necessary state, including 2. Unique Session Identifier for the Server Node V^^V 

state variables which indicate a level of authorization for the 3 Time of session creation Wji^ 

client's use of the session. 4i Expiration (Time-to-live) of session i>V*^ 

One instance where migration is useful is where an 45 5. User ID 

operator of a Web server wants to out source the operation 6. E-mail address 

of a particular aspect of their Web site. For example, a 7. Telephone number 

newspaper might operate a site which provides news, fea- 8. Postal address 

tures and classifieds, but will out source the management of 9. Digital Signature 

the classifieds to another operator, such as Electric 50 The server node identifier can be almost any type of 

Classifieds, Inc., of San Francisco, Calif, (the assignee of the identifier, including numerical values or ASCII strings. The 

present application). A migration occurs when a user selects server node identifier might be an identifier specific to 

a classifieds "button" or selection on a Web page operated by cooperating servers or could be a unique code already in use 

the newspaper. The URL associated with the button can by the server such as its four-byte IP address or six-byte IP6 

either be a direct reference to the target server or a reference 55 address. The only requirement is that no two cooperating 

which causes redirection. In the former case, the page server nodes share the same identifier. The session is 

containing the button is presented to the user with the uniquely identified by the first two elements in the session 

underlying HTML anchor including a session token for use token, since the second element is unique within the source 

in migration. This is possible where the source server can server node. By dividing the session identifier into two 

anticipate that a migration may occur. In the latter case, the co pieces, we allow for the decentralized generation of session 

server need not anticipate the migration and the anchor for identifiers. Some of the session token elements, such as the 

the button will be a URL directed at the source server. The e-mail address, telephone number and postal address, might 

source server responds to the URL with a redirection URL. be optional elements. 

The redirection URL would be the equivalent to the embed- As shown in FIG. 3, a session token such as session token 

ded URL with a session token in the former case. 65 104 is divided into a plaintext portion 300 containing the 

A session migration using a redirection URL is illustrated session ID and a ciphertext portion containing the encrypted ^ \Y/v\< aJo 

in the flowchart of FIG. 2. FIG. 2 shows a number of steps session information 302 to allow for more secure transport 
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of session token in form a lion. With public key encryption, particular migration, or any other reasons, server B sends an 

the information can be made secure by digitally signing it, error message 110 back to the client. Otherwise, server B 

v to prevent forgery, or by encrypting it, to prevent forgery and processes the information in session token 104 and out-of- 

to prevent others from reading the session data. In Table 1 , band data 108, if used, and sends an acceptance message 112 

jjUhe encrypted session information is the third through eighth 5 t o the client (Sll). Acceptance message 112 can either be a 

/^elements, which are not required to uniquely identify the server to client message or a server to user message such as 

ypSp session. Therefore, these fields can be sent encrypted yet be a welcome message. In the former case, the transition might 

rfpo decrypted at the target server node using an encryption be a transparcn t transition. The client responds (S12) by 

method and key specific to the session. If the encryption transitioning to the new and reqU esting services from 

method and key is the same for all session tokens from a 10 &erver fi (S]3) which sefver B seryices ^ me mi d 

particular source server node, the second element can also be , , • ^ V. • /C1 A> . 

r 4 , - 4 . ■ •£ * c state information (S14). 
encrypted. Encryption of the session specific information is 

preferred, so that unauthorized parties cannot view the Versioning 

information. In some embodiments, the information in the To minimize the retransmission of data that a target server 

session token is not readable by the client even when the 15 node already has, the target server node may choose to cache 

client is in possession of the session token. Of course, the out-of-band data obtained from a source server node. Of 

user might be able to view his or her own session informa- course, in a distributed network, cache consistency can be a 

tion through the use of a dummy server. A dummy server problem. Cache inconsistencies might occur when session 

accepts the user's migration like any other server, but then information changes and a client is not connected to the 

does nothing more than display the session information. 20 target server node caching the data. It is important for those 

Table 1 shows but one example of a format for a session changes to work their way around to other server nodes. 

t0k n n ' ^ ter ; eadin S ^ s description, the person of ordinary A method for doi ^ ^ ^ encode a vefsion identifier 

skill will understand that other formats are possib e, so long within the session tokcn such (hat whencvcr any out . 0 f-band 

as the format have certain properties. For example, session session information changes> the source server node 

tokens must be unique so as to uniquely identify a session 25 win ch the yersion identifieL whcncV er a new 

and must be such that they can be generated in a distributed session tQken ^ generated by the ^iver node> lne 

^ environment, i.e., without a centralized session token gen- new version identifier wilI be passed on to a target server 

erator. They should be difficult for unauthorized parties to node If the vefsion identifier within the token i ndicates tha t 

modify or forge. Tney must also be able to pass information Qther informalion newer than lhe data that the target server 

about the session, or at least refer to information about the 30 node iousl has used> the larget server should request 

session, which may then later be transferred out-of-band. Qew out . of . band session information from the source server 

While the system may operate without digital signatures, the Qodc 

use of digitally signed session tokens is preferred. A digitally _* ..... 

j ■ , i • • j • ,u , a L Different granularities of version numbers may be used 

signed session token is signed using the source server node s „ , ■ c ^ , . , 

/ • . t_ , tUnt iu„ A-Zi»\ • „„„ u„ i „ „ for out-of-band session information. For example, a single 

/ pnvate key so that the digital signature can be verified using 35 . , t „ t1 r - . , 

f, . , u . , it • j" ■* i 4 version number may represent the state ot all out-of-band 

the source server node's public key. Using a digital signature , ? . , F 

„ 4 . «v - t c *u * i . c a • data items, or multiple version numbers may represent 

allows the authenticity of the token to verified. ■*. • . fl . , r L j j ♦ ^_ i-fj 

^ v , • tU * i f ™ a certain subsets of the out-of-band data. The granularity does 

Once the client receives the session token from server A, _ , , . _ , , ' . 

4l _ ,. t ■* « i -\t\A t *\. i, i a not affect the cache updating per se. Instead, the granularity 

the client sends session token 104 to the target server node, „ . . , . . , . j . 

n oa\ e~.,,~, o „ , rt i>„„ i n j An of versioning merely determines how much data must be a 

server B (step S4). Server B processes session token 1U4 40 » . , J *. ■ . r • c »\ 

r ■ A. -a r a a _«* re -transferred in the case of the change or session inform a- %y 

(S5), performing the necessary verification and decrypting . 6 v J 

of the session token. In some cases, the session token makes tlon ' 

reference to "out-of-band" data, i.e., data which is not One application for the present invention is within the 

contained within the session token but which is state infor- World Wide Web, where session tokens are encoded within >yV> 

mation needed for migration. Out-of-band data is used to 45 URLs. When a session is to be migrated from a source server 

, keep session tokens from being too large, or for tighter node to a target server node, a new URL will be generated 

/ access control. For example, the user's postal address might for a session token. A client application will then make a y 

^ be specified as a pointer to a specific record of a database request to the target server node using this URL. The target 

controlled by server A. Server B checks to determine if server node w*U then decode this session token, verify its 

out-of-band data is needed (S6). If out-of-band data is 50 authenticity (using public key cryptography) and obtain any 

needed, server B forms a request 106 for the data using necessary out-of-band session information before continu; 

session token 104 and sends request 106 Xo server A (S7). ing with the request. Preferably, the session token is limited 

Session token 104 is part of the request so that server.A can in size so tnat raost browsers and HTTP handlers can 

verify that server B is making an authorized request, FIG. 4 correctly process the session token as a URL. A limit many 

shows the structure of request 106, which is an envelope 55 browsers have for URLs is 1 kilobyte. If the session infor- 

containing request details 400 and the session token 104. In mation is greater than the limit, some of the session infor- 

some embodiments, not all the session information is passed mation is sent as out-of-band data. 

to the source server node. In the preferred embodiment, the encoded session token T^Ca^JsC- 

When server A receives request 106, it supplies the will be in a modified Base-64^ which is a standard encoding 

out-of-band data to server B (S8) in a response 108. Server 60 for MIME email documents (Multipurpose Internet Mail 

B parses and stores response 108 (S9) and proceeds to step Extensions). A Base-64 data stream is a stream of 6-bit 

S10. If out-of-band data is not needed, server B proceeds numbers represented by an alphabet of 64 alphanumeric 

directly from step S6 to step S10. At step S10, server B characters (usually the uppercase letters A-Z, the lowercase 

decides whether to accept the server migration request letters a-z, the digits 0-9, and the characters and 7'. For 

represented by session token 104. If server B decides not to 65 our purposes, we use a modified Base-64 wherein and 

honor the migration because the identified client is not are used in place of V and 7 1 so as to generate HTTP 

authorized to use server B, server B does not support that compliant URL's. 
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Before it is encoded into modified Base -64 for transmis- 
sion using HTTP, the session token has the format shown in 
Table 2. 

TABLE 2 



Ser- 
ver 



Output 



Bytes 


Web Session Token Format 
Description 




1 


Token Format [D 


10 


6 


Session Identifier 




2 


Length (N) of data to follow 




N 


Session Data 




4 


CRC Checksum (32 bit) 





123 



456 



15 



The Token Format ID should be zero. This field is 
reserved as a way to specify new token formats should there 
be a need to change them in the future. The session identifier 
is a 64-bit ID comprising 16 bits (2 bytes) for a server node 
ID and 48 bits (6 bytes) for a unique session ID for the server 20 
node. This assumes a cooperating network of 2" 16 servers or 
fewer each assigned a unique server node ID. The N bytes 
of session data is encrypted with target server node's public 
key and digitally signed with source server node's private 
key. Encryption is done using a public key cryptosystem 25 
supplied by RSA Data Security, of Palo Alto, Calif., or 
similar cryptosystem. 

Before the session data is encrypted and signed, it has the 
following format, which is very similar to the RFC 822 
electronic mail header format: 30 

<KEY1>: <VALUE1> 
<KEY2>: <VALUE2> 

<KEYM>: <VALUEM> 35 
In this format, a key and its associated value are separated 
by a colon (and optional whitespace) and key/value pairs are 
separated by newline characters. An example of session data 
is as follows: 

Version-Date: Fri Dec 30 10:14:46 PST 1994 40 
User-ID: Fred 

Email-Address: fred@fred.org 
Telephone: @123.Fred.Telephone 

Postal-Address: @ 123 .Fred. Address 45 
The "Telephone:" key value, "@ 123 .Fred .Telephone", is 
an indirect reference to session information which indicates 
that Fred's telephone number is actually held at server node 
123 and should be queried from that server node, using the 
data identifier "Fred.Telephone". To implement the out-of- 50 
band transferal of session information, a simple transfer 
protocol for making queries over a secure out-of-band 
channel is used. The secure out-of-band channel (depending 
upon the circumstances) may be implemented as a private, 
dedicated physical link (such as a dedicated, private Tl line), 55 
or may be implemented as a secure link over a public 
network using an encrypted tunnel (such as with SSL, 
Secure Sockets Layer), 

A querying server node wishing to obtain session infor- 
mation from a source server node would simply open a 60 
connection with the source server node, identify itself (the 
querying server node), get authenticated and then make a set 
of queries to obtain session data. The following is an 
example of the process where a querying server node 
(identified as server node 456 in this example) connects to 65 
a source server node (identified as server node 123) to 
request out-of-band data: 



Connected to server 123, please identify and 
authenticate self 
Server: 456 
Signature REOp5XtI5XtIpWxltBY6maOwRXuyNz 
123 Server 456 authenticated, 

please make your requests. 
456 Fred.Telephone, Ftcd. Address 
123 Fred.Telephone: (345) 555-1212 

Fred. Address: 12345 Main Stieel 

Anytown, USA 98765-1234 

456 QUIT 

123 Goodbye, server 4S6. 



In addition to the above-described applications, other 
applications can be found for the present invention. One use 
of transparent session migration is a child filter. If a child is 
logged into a service, that child may see different informa- 
tion than if an adult were logged into the same service. As 
the child migrates from server to server, an indication that 
the user is a child will be included in the session information 
so that the target server node can adjust its content accord- 
ingly. 

The above detailed description explains how to make and 
use a session migration method and apparatus according to 
the present invention. The above description is illustrative 
and not restrictive. Many variations of the invention will 
become apparent to those of skill in the art upon review of 
this disclosure. The scope of the invention should, therefore, 
be determined not with reference to the above description, 
but instead should be determined with reference to the 
appended claims along with their full scope of equivalents. 

What is claimed is: 

1. In a client-server network having multiple independent 
servers, a method of session migration from a session 
between a client and a first server to a session between the 
client and a second server; 

establishing a current session between the client and the 
first server after the first server has verified that th e 
client is an authorized client of the first server; 

sending a migration request firom the client to the first 
server; 

in response to the migration request generating a session 
token; 

sending a session token from the first server to the client, 
wherein the session token uniquely identifies the cur- 
rent session between the client and the first server; 

sending the session token from the client to the second 
server as a request to the second server for migration; 

verifying, at the second server and from the session token, 
the identity of the client and the first server; 

requesting, from the first server, data about the session, 
wherein the request is sent from the second server; 

responding from the first server to the request for data by 
sending the requested data to the second server; and 

if the client is an authorized client with respect to the 
second server, continuing the session with the second 
server in place of the first server. 

2. The method of claim 1, wherein the client- server 
network is the Internet and the first and second servers are 
hypertext transfer protocol servers. 

3. The method of claim 1, wherein the step of generating 
a session token is a step of generating an encrypted session 
token. 
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4. The method of claim 3, wherein the step of generating 8. The method of claim 1, wherein the step of generating 
an encrypted session token comprises the steps of encrypting the session token is performed without a central token 
portions of the session token and including a digitally signed repository yet is guaranteed to be a unique session token, 
portion in the session token, the digitally signed portion 9. The method of claim 1, further comprising a step of 
being digitally signed by a private key of the first server. 5 transferring the requested data using a protocol other than a 

5. The method of claim 1, wherein the step of sending a hypertext transfer protocol. 

session token from the first server to the client is a step of 10 ^ method of claim x comprising a slep of 

sending a session token containing a digitally signed maintaining a version control number and requesting from 

portion, the digitally signed portion being digitally signed by ^ fifSt gerver ^ which fc an update to data . received 

a private key of the first server 10 iousl at the secoad se the dale 5ei ^ date 

6. The method of claim 1, further comprising the steps of: £ . . c , t . *, j , 

' r & t~ from a previous version of the data identified by a version 

requesting a password from the client; number stored on the second and a current version of 

sending the password to the first server; me data identified by a version number stored on the first 

if the password matches a predetermined criterion indi- 5 server, 

eating an authorized client, continuing with the step of u. The method of claim 1, wherein the session migration 

establishing a session; is from one World Wide Web server to a second World Wide 

sending, as part of the session token, an indication from Web server, and the client is a World Wide Web browser, 

the first server, that the client is an authorized client; 12. The method of claim 1, wherein each step of sending 

and 20 a session token comprises sending at least a part of the 

using the indication from the first server as a substitute for session token in a uniform resource locator. 

a logon procedure used by the second server to verify 13. The method of claim 1, wherein each step of sending 

the authorization of the client. a session token comprises sending at least a part of the 

7. The method of claim 1, further comprising a slep of session token in a hypertext transport protocol cookie, 
forming a uniform resource locator representing the session 25 

token. ***** 
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